1. Background and Relevant Art
As computerized systems have increased in popularity, so have the needs to communicate with other people and applications associated therewith. In general, computer systems and related devices communicate information over a network for a variety of reasons, for example, to exchange personal electronic messages, sell merchandise, provide account information, to communicate messages from one application to another, and so forth. One will appreciate, however, that as computer systems and their related applications have become increasingly more sophisticated, the challenges associated with communicating messages on a network have also increased.
Generally, there are a number of different protocols and topologies for communicating messages from one computer system to the next over a network. One conventional topology, such as used with electronic mail (“email”) and some instant messenger systems, uses one or more centralized messaging servers to manage and verify user information, and also to route user messages sent from one computer system to the next. In this example, one computer system logs in to the centralized message server and sends a message addressed to another user or computer system. The centralized server receives the addressed message, verifies user information, and sends the message addressed to the computer system (or user).
Another conventional topology uses a peer-to-peer framework to send messages directly from one computer system to the next. That is, one computer system (i.e., one “peer” or “peer computer system”) might connect directly to another computer system (i.e., another “peer” or “peer computer system”), and then send messages directly to the other peer computer system. Conventional peer connections such as these might also have several other connections with multiple different other peer computer systems. In particular, one peer might also be connected to multiple other peers in the communication network, and might further be connected to a defined “group” of multiple peers.
Conventional peer communication frameworks such as these, however, are more limited in many ways in how they facilitate communication compared with conventional email or instant messaging systems. For example, conventional peer communication frameworks do not typically allow for groups to include other groups. That is, a peer group typically comprises a membership of one or more peer computer systems, but does not typically include in its membership a single entity (e.g., an address or object) representing another group, without perhaps separately addressing all members of that other group.
Conventional peer communication frameworks also typically have few—if any—services that adequately or intelligently regulate the number and means for communicating certain messages. For example, one peer might send a message to a couple of other peers in a defined group. The recipient peers might further relay the message to a few other peers in the group without discriminating who originally sent the first message. As such, the original sending peer might receive several copies of the original message from other members of the peer group.
In addition, conventional peer frameworks do not efficiently—if at all—distinguish how, when, or if the user received an answer to the query. For example a user might want to send a query to several members of a peer group, but only needs to receive the correct answer once. Nevertheless, unless the peer group members are sent another message of some sort that the query has been satisfied, each peer group member might think that there has not yet been a response to the query, and thus continue to respond. As a result, the user could conceivably get several iterations of the same answer from multiple peers in a group for only a single question. Along these lines, a conventional peer communication framework also does not typically distinguish one peer member from the next inside a peer group very well. For example, a peer might need to transmit certain information only once to one member of a peer group, such as to join the peer group, but not want (or need) to communicate that information to all members of the peer group. Unfortunately, conventional peer frameworks do not allow for this type of constraint.
One can appreciate, therefore, that a conventional peer communication framework might have many unnecessary copies of messages floating around the network in various stages. That is, there may be many unnecessary message duplicates being sent around a peer network due to failures of distinguishing between peers, or whether peers have originated or received a message, such as in the scenarios just described. In other cases, the peer communication framework might be clogged with messages sent using a certain communication mechanism that is inappropriate for a given context, where the end-user might not be even able to access the peer-to-peer message.
For example, a peer communication framework might use a Hypertext Transfer Protocol (“HTTP”) mechanism for sending messages to a user based on some initial connection information. If the user leaves the local computer system (i.e., walks out of a building), however, it may be more efficient to communicate the message to the user's mobile phone using a Short Message Service (“SMS”) communication mechanism. Nevertheless, a conventional peer communication framework will not automatically adjust its chosen communication mechanism to accommodate a change in presence. In particular, the peer communication framework will typically use an “all-or-nothing” approach, and remain only with an initially chosen communication mechanism, regardless of whether another communication mechanism might be more appropriate at a later time. One can appreciate that the failure to appropriately modulate how many and what messages are being sent can result in taxing the peer communication framework.
Another aspect of conventional peer communication frameworks is that they do not normally take possible constraints into account (e.g., hardware, software, or both) when distinguishing “listening” and “sending” behavior at a peer. For example, a sending peer may want to only broadcast information, as in the case of distributing stock quotes, while a listening peer might want to only listen to the broadcast information, as in the case of simply viewing a stream of the stock quotes. The sending and listening peers each might further be using two different types of communication channels with different capabilities. For example, one communication channel might have a fast upload speed and slow download speed, while another communication channel might have an equal but moderately fast upload and download speed. Conventional peer frameworks, however, typically do not determine appropriate communication channels (or other hardware or software determinations) based at least in part on the type of peer behavior, or appropriately adjust the determination after establishing a peer connection.
Accordingly, conventional peer-to-peer communication can be optimized for a wide variety of considerations.